<!doctype html public "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html>
<!-- Generated from TeX source by tex2page, v 4o, 
     (c) Dorai Sitaram, http://www.cs.rice.edu/~dorai/tex2page -->
<head>
<title>
Structure and Interpretation 
of Computer Programs
</title>
<link rel="stylesheet" type="text/css" href="book-Z-C.css" title=default>
<meta name=robots content="noindex,follow">
</head>
<body>

<p><div class=navigation>[Go to <span><a href="book.html">first</a>, <a href="book-Z-H-18.html">previous</a></span><span>, <a href="book-Z-H-20.html">next</a></span> page<span>; &nbsp;&nbsp;</span><span><a href="book-Z-H-4.html#%_toc_start">contents</a></span><span><span>; &nbsp;&nbsp;</span><a href="book-Z-H-38.html#%_index_start">index</a></span>]</div><p>

<a name="%_chap_3"></a>
<h1 class=chapter>
<div class=chapterheading><a href="book-Z-H-4.html#%_toc_%_chap_3">Chapter 3</a></div><p>
<a href="book-Z-H-4.html#%_toc_%_chap_3">Modularity, Objects, and State</a></h1><p>

<p>

<p>
<div align=right> 
<table width=60%><tr><td>
<span class=epigraph>
<p>

M<img src="ch3-Z-G-1.gif" border="0"><p>

<p><p><p>

(Even while it changes, it stands still.)<p>

<a name="%_idx_2820"></a>Heraclitus<p>

Plus &ccedil;a change, plus c'est la m&ecirc;me chose.<p>

<a name="%_idx_2822"></a>Alphonse Karr<p>

</span>
</td></tr></table>
</div>

<p><p>

The preceding chapters introduced the basic elements from which
programs are made.  We saw how primitive procedures and primitive data
are combined to construct compound entities, and we learned that
abstraction is vital in helping us to cope with the complexity of
large systems.  But these tools are not sufficient for designing
programs.  Effective program synthesis also requires organizational
principles that can guide us in formulating the overall design of a
program.  In particular, we need strategies to help us structure large
systems so that they will be <em>modular</em>, that is, so that they can
be divided ``naturally'' into coherent parts that can be separately
developed and maintained.<p>

<a name="%_idx_2824"></a><a name="%_idx_2826"></a>One powerful design strategy, which is particularly appropriate to the
construction of programs for modeling physical systems, is to base the
structure of our programs on the structure of the system being
modeled.  For each object in the system, we construct a corresponding
computational object.  For each system action, we define a symbolic
operation in our computational model.  Our hope in using this strategy
is that extending the model to accommodate new objects or new actions
will require no strategic changes to the program, only the addition of
the new symbolic analogs of those objects or actions.  If we have been
successful in our system organization, then to add a new feature or
debug an old one we will have to work on only a localized part of the
system.<p>


To a large extent, then, the way we organize a large program is
dictated by our perception of the system to be modeled.  In this
chapter we will investigate two prominent organizational strategies
arising from two rather different ``world views'' of the structure of
systems.  The first organizational strategy concentrates on <a name="%_idx_2828"></a><em>objects</em>, viewing a large system as a collection of distinct objects
whose behaviors may change over time.  An alternative organizational
strategy concentrates on the <a name="%_idx_2830"></a><em>streams</em> of information that flow in
the system, much as an electrical engineer views a signal-processing
system.<p>

Both the object-based approach and the stream-processing approach
raise significant linguistic issues in programming.
With objects, we must be concerned with how a computational object can
change and yet maintain its identity.  This will force us to abandon
our old substitution model of computation
(section&nbsp;<a href="book-Z-H-10.html#%_sec_1.1.5">1.1.5</a>) in favor of a more mechanistic
but less theoretically tractable <a name="%_idx_2832"></a><em>environment model</em> of
computation.  The difficulties of dealing with objects, change, and
identity are a fundamental consequence of the need to grapple with
time in our computational models.  These difficulties become even
greater when we allow the possibility of concurrent execution of
programs.  The stream approach can be most fully exploited when we
decouple simulated time in our model from the order of the events that
take place in the computer during evaluation.  We will accomplish this
using a technique known as <a name="%_idx_2834"></a><em>delayed evaluation</em>.<p>


<p><div class=navigation>[Go to <span><a href="book.html">first</a>, <a href="book-Z-H-18.html">previous</a></span><span>, <a href="book-Z-H-20.html">next</a></span> page<span>; &nbsp;&nbsp;</span><span><a href="book-Z-H-4.html#%_toc_start">contents</a></span><span><span>; &nbsp;&nbsp;</span><a href="book-Z-H-38.html#%_index_start">index</a></span>]</div><p>

</body>
</html>
